Background
On 6th August 2014 the OpenSSL project released 1.0.1i that fixed several security vulnerabilities of moderate severity or less. Official OpenVPN Windows installers bundle OpenSSL 1.0.1, which meant that the OpenVPN project had to make a new Windows installer release. On *NIX-based operating systems upgrading OpenSSL is typically handled by the OS provider.
List of vulnerabilities
| Vulnerability name | ID | Affects OpenVPN? |
|---|---|---|
| Information leak in pretty printing functions | CVE-2014-3508 | Possibly[1]. |
| Crash with SRP ciphersuite in Server Hello message | CVE-2014-5139 | No. OpenVPN does not use SRP. |
| Race condition in ssl_parse_serverhello_tlsext | CVE-2014-3509 | No. |
| Double Free when processing DTLS packets | CVE-2014-3505 | No. OpenVPN does not use DTLS. |
| DTLS memory exhaustion | CVE-2014-3506 | No. OpenVPN does not use DTLS. |
| DTLS memory leak from zero-length fragments | CVE-2014-3507 | No. OpenVPN does not use DTLS. |
| OpenSSL DTLS anonymous EC(DH) denial of service | CVE-2014-3510 | No. OpenVPN does not use DTLS. |
| OpenSSL TLS protocol downgrade attack | CVE-2014-3511 | No. OpenVPN already defaults to TLS 1.0 [2]. |
| SRP buffer overrun | CVE-2014-3512 | No. OpenVPN does not use SRP. |
[1] This one triggers no direct vulnerability in OpenVPN. Leaked information is not sent to peers by OpenVPN. It might be possible that the leaked information is passed on to a client script / plugin (not sure what form the leaked information has, if the leaked information is after a NUL-byte, it's probably not even exported). Such a plugin/script could then leak the information to the attacker.
[2] If you are using OpenVPN 2.3.3 or OpenVPN 2.3.4 and have enabled newer TLS versions by using option tls-version-min in your configuration, your configuration is vulnerable to the protocol downgrade attack. However, it will still be at least as secure as a setup without tls-version-min in its configuration.